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REMARKS 

The following remarks are presented in response to the Final Office Action of 
September 8, 2006. The Applicant respectfully requests reconsideration and allowance 
of the present application in view of these remarks. 

Regarding the 35 U.S.C. § 102(b) Rejection 

Claims 1-12, 15, 17-36, and 48-49 are rejected under 35 U.S.C. § 102(b) as being 
anticipated by Altova, Inc., "XML Spy 4.0 Manual," (referred to below as "Altova" for 
brevity). Applicant respectfully traverses this rejection for the following reasons. 

Altova describes version 4.0 of the XML Spy product. Altova states that the 
purpose of the XML Spy product is to simplify typical XML editing tasks (see page 2). 
Altova describes the presentation of XML information in multiple different views: an 
Enhanced Grid view; Schema view; Text view; and Browser view (see page 19). Altova 
provides examples of editing performed in the Text view and Enhanced Grid view (see 
pages 56-59). In another section, Altova describes an XSL transformation, which 
involves assigning a predefined Company .xsl file to an XML document, and using this 
XSL file to transform the XML document into an HTML document (see pages 73-76). In 
another section, Altova describes an XML Spy Document Editor that enables a user to 
edit XML documents based on templates created in a product referred to as XSLT 
Designer (see pages 343-362). Altova shows presentations generated by the XML Spy 
Document Editor which includes visible markup symbols (e.g., see the top figure of page 
355). 

Altova does not anticipate any of the claims. To begin with, consider claim 1, 
which is reproduced below in its entirety: 
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1 . A method for mapping between parts of an input document and associated parts 
of an output document, the input document pertaining to a first kind of document, and the 
output document pertaining to a second kind of document, comprising: 

providing a translation file that converts documents of the first kind to documents of 
the second kind; 

in a first phase, modifying the translation file to include mapping functionality that 
can provide information regarding relationships between parts of documents of the first kind 
and associated parts of documents of the second kind, the first phase producing a modified 
translation file; 

in a second phase, using the modified translation file to convert the input document 
into the output document, including: 

activating the mapping functionality; and 

using the mapping functionality to provide references in the output 
document that associate parts of the output document with parts of the input 
document. 

Altova does not describe the invention recited in claim 1 . As noted above, Altova 
shows multiple ways of viewing XML information, including a Text View and a Browser 
view. Further, Altova shows the display of XML markup symbols in a document. 
However, Altova does not disclose the technical manner in which it achieves these 
results, and therefore does not disclose the specific subject matter of claim 1. For 
instance, Altova does not describe at least the following parts of claim 1, when read in the 
context of the claim as a whole: 
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in a first phase, modifying the translation file to include mapping functionality that 
can provide information regarding relationships between parts of documents of the first kind 
and associated parts of documents of the second kind, the first phase producing a modified 
translation file; 

in a second phase, using the modified translation file to convert the input document 
into the output document, including: 

activating the mapping functionality; and 

using the mapping functionality to provide references in the output 
document that associate parts of the output document with parts of the input 
document. 

The essence of the Office Action's response to the above-described position is 
that the claimed subject matter is inherent to Altova's description. Consider the 
representative argument provided on page 25 of the Office Action, which states, in part: 

It is noted that a first phase, modifying the translation file to include mapping 
functionality that can provide information regarding relationships between parts of document 
of the first kind and associated parts of documents of the second kind, the fits [sic] phase 
producing a modified translation file,' is inherent if processing a document through an XSL 
transformation. Additionally, such relationship functionality in a 'first phase' is found in any 
stylesheet translation. 

Further, it is noted that 'a second phase, using the modified translation file to 
convert the input document into the output document,' is also inherent in the use of an XSL 
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transformation. Still farther, a "mapping functionality' providing 'references in the output 
document that associate parts of the output document with parts of the input document' is 
expressly taught in XML Spy. (Note page 25 of the Final Office Action.) 

The Applicant submits that this argument is in error. As to the Patent Office's 
reliance on inherency, MPEP § 21 12 states that, "In relying upon the theory of inherency, 
the examiner must provide a basis in fact and/or technical reasoning to reasonably 
support the determination that the allegedly inherent characteristic necessarily flows from 
the teachings of the applied prior art." Ex parte Levy, 17 USPQ2d 1461, 1464 (Bd. Pat. 
App. & Inter. 1990) (emphasis in original). The fact that a certain result or characteristic 
may occur or be present in the prior art is not sufficient to establish the inherency of that 
result or characteristic. In reRijckaert, 9 F.3d 1531, 1534, 28 USPQ2d 1955, 1957 (Fed. 
Cir. 1993). These factual and legal requirements are not satisfied by the Patent Office's 
rejection based on Altova. 

Consider, for example, page 12 of Altova. This excerpt of Altova shows a screen 
shot that includes a window that displays an XML document in a first view and another 
window that displays the same document in a second "Browser" view. This excerpt of 
also states that the Browser view is produced using an XSL Stylesheet. An XSL 
transformation is one exemplary and non-limiting manifestation of a translation file. The 
question remains of how Altova produces these results. The Applicant submits that it is 
not inherent that Altova performs the above-identified operations recited in claim 1, such 
as, "in a first phase, modifying the translation file to include mapping functionality that 
can provide information regarding relationships between parts of documents of the first 
kind and associated parts of documents of the second kind." In other words, even if, 
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assuming arguendo, that Altova performs mapping between different views, this does not 
support the conclusion that Altova performs the specific operation of modifying a 
translation file (such an XSL file) to include such mapping functionality. 

Indeed, other portions of Altova support the conclusion that Altova does not, in 
fact, add mapping functionality to a translation file. For instance, note the exemplary 
listing of an XSL file on page 15 of Altova. There is no characteristic or telltale markup 
in this listing which indicates that special mapping functionality has been added to the 
XSL file. While the present specification does not limit the claims, it is instructive to 
compare page 15 of Altova with Fig. 5 of the present specification, where, in step 504, 
mapping functions (508, 510) are added to arbitrary XSLT markup (shown in step 502). 
There is no such similar markup shown on page 15 of Altova to indicate that Altova is 
adding mapping functionality to a translation file. 

Fig. 5 of the present specification, while not limiting the claims, is also instructive 
in rebutting the Patent Office's position that any conventional XSL Stylesheet inherently 
performs the functions defined in claim 1. Fig. 5 shows that arbitrary XSLT markup 
(shown in step 502) is specifically modified (in step 504) to include mapping 
functionality. If conventional off-the-shelf XSLT already performed the unique functions 
described here, there would be no need for the operation shown in step 504. As described 
more fully in the Background section, conventional XSLT converts from a first format to 
a second format, but does not provide backward-mapping from the second format to the 
first format. 

An analogy may be helpful in clarifying the above arguments. Consider the 
hypothetical case in which a module converts an English document to a German 
document using a translation file, where the translation file is a hypothetical off-the-shelf 
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module which converts certain words in the English document to corresponding words in 
the German document. Suppose next that a reference shows a split screen display 
including a depiction of the original English document in one part and the converted 
German document in another part, showing how parts of the German document are linked 
to corresponding parts of the English document. The salient question is how this 
operation is performed. One way to perform this operation that is inspired by the 
principles of the present specification is to modify a pre-existing translation file to include 
mapping functionality. But another possible hypothetical solution would be to use an 
entirely independent mapping module that does not operate by modifying the translation 
file. Another possible solution would be to rely on a human user to manually add 
mapping functions to the final German document. There may be yet other solutions. The 
point of this exercise is not to suggest that these various hypothetical solutions are 
obvious per se, or that these solutions are obvious in view of each other. Rather, the 
point is merely to illustrate that there are, in fact, multiple possible ways to produce the 
above-described end result of mapping between an English document and a German 
document. Hence, it cannot be said that one solution is inherently taught by a screen shot 
that illustrates only the end result - because one solution does not necessarily follow from 
the end result 

To reiterate, the MPEP passage quoted above require that "In relying upon the 
theory of inherency, the examiner must provide a basis in fact and/or technical reasoning 
to reasonably support the determination that the allegedly inherent characteristic 
necessarily flows from the teachings of the applied prior art." Insofar as the Examiner's 
conclusions do not necessarily flow from Altova, the argument based on inherency is in 
error. Further, as argued above, what Altova does expressly disclose supports the 
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contrary conclusion that Altova does not produce its end result using the unique two- 
phase approach set forth in claim 1 . 

Continuing on, page 26, lines 3-5 of the Office Action states that "In that the 
document was able to track back and forth between the original and translated versions, it 
is inherent that there is a mapping functionality between the input and output 
documents." This analysis does not reflect what is specifically being recited in claim 1. 
Even if, assuming arguendo, that Altova shows, from an end user perspective, tools for 
relating two documents expressed in different formats, claim 1 recites a two-phase 
operation that expressly involves "modifying the translation file to include mapping 
functionality," rather than nebulously providing mapping functionality that is somehow 
involved in mapping between two kinds of documents. Altova does not expressly 
disclose at least this modifying operation. What is specifically being claimed must be 
addressed, not a loose paraphrasing of what is being claimed. 

The Office Action's other points of argument raised on pages 25 and 26 are 
believed to be adequately addressed by the above discussion. 

In conclusion, the Applicant submits that no portion of Altova expressly or 
inherently discloses the subject matter of independent claim 1. Independent claims 17 
and 29 recite related subject to claim 1, and therefore distinguish over Altova for reasons 
that are similar to those provided above with respect to claim 1 . 

Next consider independent claim 15, which is reproduced below in its entirety: 

15. A method for generating mapping functionality that can map between parts of 
an input document and associated parts of an output document, the input document 
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pertaining to a first kind of document, and the output document pertaining to a second kind 
of document, comprising: 

providing a translation file that converts documents of the first kind to documents of 
the second kind; and 

modifying the translation file to include mapping functionality that can provide 
information regarding relationships between parts of documents of the first kind and 
associated parts of documents of the second kind. 

Altova does not disclose the providing and modifying operations recited in claim 
15. For instance, while XSLT is conventionally used to translate from XML to HTML 
and therefore can be construed as one exemplary variety of a translation file, Altova does 
not describe that its various features are produced by modifying a translation file to 
include mapping functionality in the manner recited in claim 15. 

Page 27 of the Office Action sets forth the position that what is being claimed is 
inherent to what Altova does disclose. However, for reasons that are related to those set 
forth with respect to claim 1 , the claimed operations do not inherently flow from what 
Altova discloses, at least because: (a) there are other possible ways to achieve the end 
result shown by Altova; and (b) the translation files set forth in Altova do not include 
mapping functionality. 

In addressing claim 15, the Office Action states, in part, "Claim 15 merely 
specifies that a mapping functionality exists and that it operates on the data after input of 
the original document and before output of the final document." This does not accurately 
describe what is being recited in claim 15. To repeat, at issue here is not whether Altova 
nebulously discloses some way of relating input and output documents, but whether 
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Altova discloses (either expressly or inherently) the specific claimed subject matter of 
claim 15, including, for instance, "modifying the translation file to include mapping 
functionality." For reasons similar to those set forth above for claim 1, Altova does not 
disclose this subject matter. Nor is this subject matter inherent to (e.g., necessarily 
flowing from) what Altova does disclose. 

For at least the above-identified reasons, Altova does not disclose the subject 
matter of independent claim 15. Independent claim 30 recites related subject to claim 15, 
and therefore distinguishes over Altova for reasons that are similar to those provided 
above with respect to claim 1 . 

Next consider independent claim 3 1 , which is reproduced below in its entirety: 

3 1 . A computer readable medium having stored thereon an information structure, 
comprising: 

a plurality of translation elements configured to convert a first kind of document 
into a second kind of document; and 

a plurality of functions interspersed amongst the plurality of translation elements, 
the plurality functions configured to provide a respective plurality of references, wherein the 
references provide pointers that link parts of the second kind of document with parts of the 
first kind of document. 

Altova does not disclose a plurality of translation elements in conjunction with a 
plurality of functions which are interspersed amongst the plurality of translation elements 
in the manner recited in claim 31. For instance, while XSLT is conventionally used to 
translate from XML to HTML documents and therefore can be construed as one 
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exemplary variety of a file containing translation elements, Altova does not describe that 
its various features are produced by interspersing a plurality of functions amongst the 
translation elements. 

Page 28 of the Office Action sets forth the position that what is being claimed is 
inherent to what Altova does disclose. However, for reasons that are related to those set 
forth with respect to claim 1, the claimed operations do not inherently follow from what 
Altova discloses, at least because: (a) there are other possible ways to achieve the end 
result shown by Altova; and (b) the translation files illustrated in Altova do not show a 
"plurality of functions interspersed amongst the plurality of translation elements." 

In addressing claim 31, the Office Action states, in part, that "There is nothing in 
the claim or specification to indicate that 'a plurality of translation elements in 
conjunction with a plurality of functions which are interspersed amongst the plurality of 
translation elements' is anything more than the inherent elements and functions within a 
sophisticated translation program, such as XSL, which is expressed taught in XML Spy." 
This argument is misplaced, as the present specification makes abundantly clear how 
certain unique mechanisms are used to modify conventional XSLT files, indicating, of 
course, that conventional XSLT files do not already include these mechanisms. Note Fig. 
5, for example, which shows that unique functions (508, 510) are added to conventional 
XSLT markup in operation 504. Claim 31 itself distinguishes from conventional XSLT 
at least because conventional XSLT does not include the recited "plurality of functions 
interspersed amongst the plurality of translation elements." 

For at least the above-identified reasons, Altova does not disclose the subject 
matter of independent claim 31. Independent claim 34 recites related subject to claim 31, 
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and therefore distinguishes over Altova for reasons that are similar to those provided 
above with respect to claim 3 1 . 

The dependent claims are likewise not disclosed by Altova by virtue of at least 
their dependency on the above-identified independent claims. The dependent claims also 
recite additional elements which distinguish over the Altova reference. To cite one 
example, claims 9, 10, 25, and 26 recite the use of extension functions expressed in the 
extensible stylesheet language (XSL). Altova describes the use of XSL, but does not 
mention the specific use of extension functions. 

In addressing Applicant's above-stated position, the Final Office Action states "It 
is noted that 'extension functions' are disclosed as only one type of mapping functions" 
(see page 28 of the Office Action). This is true, but it is also irrelevant to the rejection of 
claims 9, 10, 25, and 26, as these claims expressly recite extension functions, and not 
some other kind of mapping mechanism. The Office Action continues by stating that 
"Based on a review of the claims and the specification, the Examiner believes that 
Applicants intended the term 'extension functions' to mean functions added to an XSLT 
document such that the functions will be mapped to the original and final documents, and 
the term will be so read for the remainder of the this Office Action" (see page 28 of the 
Office Action). The term "extension functions" is a known term in the art, referring to a 
specific mechanism used in XSLT technology. The specification discusses extension 
functions as follows: 



In one implementation, the mapping functions added by the annotation module 408 
can be implemented as so-called XSLT extension functions. More specifically, XSLT 
provides a collection of tools to accomplish certain tasks. However, the range of functions 
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that can be performed with unsupplemented XSLT is limited; XSLT cannot perform some 
tasks very well, and cannot perform other tasks at all. Extension functions constitute 
references within the XSLT information that act as triggers to call some extended 
functionality to execute tasks not provided within XSLT itself. In the instant case, the 
extension functions perform the task of adding references to the XSLT information that point 
back to respective locations in the structured data 202. To repeat, however, these mapping 
functions are not executed in phase 1; rather, in phase 1, they are merely inserted in the 
XSLT information 402 at appropriate locations. 

Altova does not describe the use of XSLT extension functions, as one skilled in 
the art would understand this term. 

Another example of a dependent claim that is not anticipated by Altova is claim 
38. This claim recites in full: 

38. The method according to claim 1, wherein the translation file is expressed in an 
arbitrary format. 

Altova does not describe performing the operations recited in claim 1, wherein the 
translation file is expressed in an arbitrary format. The Office Action states that 
'Applicants admit that a prior art translation file, such as XSLT, 'is expressed in an 
arbitrary format'," citing page 12 lines 7-15 of the present specification (pages 19-20 of 
the Office Action). That portion of the specification describes, inter alia, that the first 
phase acts on so-called arbitrary XSLT information, wherein the XSLT information is 
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arbitrary in the sense that it is not prepared specifically for the annotation mechanism 
described in the specification. 

Claim 1, from which claim 38 depends, recites, in part: 

in a first phase, modifying the translation file to include mapping functionality that 
can provide information regarding relationships between parts of documents of the first kind 
and associated parts of documents of the second kind, the first phase producing a modified 
translation file; 

Since Altova does not even disclose modifying a translation file, this reference 
clearly does not disclose that the modifying acts on a translation file that is expressed in 
an arbitrary format. The question is not the separate considerations of whether Altova 
discloses the use of XSL or whether XSL can be expressed in an arbitrary format, but 
whether Altova describes the complete procedure of claims 1 and 38, which involves 
acting on a translation file expressed in an arbitrary format. Altova does not include any 
such disclosure. Moreover, the Applicant submits that reference to the specification is 
misplaced. That portion describes that the unique first-phase operation acts on arbitrary 
XSLT, which involves adding something to arbitrary XSLT. The isolated observation 
that arbitrary XSLT exists is not on point. It is analogous to saying that adding a 
chemical X to a base chemical Y in a state Z is known based on the isolated observation 
that chemical Y is known to be in state Z. This ignores the question of whether a 
reference in fact discloses the complete inventive operation of adding chemical X to 
chemical Y. 
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Another example of a dependent claim that is not anticipated by Altova is claim 
39. This claim recites in full: 

39. The method according to claim 1, wherein the modifying is performed in a 
substantially automatic fashion. 

The "modifying" operation of claim 1 is repeated above. Since Altova does not 
even disclose modifying a translation file, this reference clearly does not disclose that 
modifying is performed in substantially automated fashion. The Office Action identifies 
page 74 of Altova as being relevant to claim 39. This portion of Altova describes 
assigning an XSL file to the an XML file, and transforming an XML document into 
HTML. This does not constituting modifying a translation file in a substantially 
automatic fashion. For example, while XSL is being used to perform translation, Altova 
does not describe that this XSL file is being modified 'to include mapping functionality. 

As stated in MPEP § 21 31 , "A claim is anticipated only if each and every element 
as set forth in the claim is found, either expressly or inherently described, in a single prior 
art reference." Verdegaal Bros. v. Union Oil Co. of California, 2 USPQ2d 1051, 1053 
(Fed. Cir. 1987). As noted above, Altova fails to disclose all of the elements in the 
independent claims. Accordingly, Altova fails to anticipate any of the claims under 35 
U.S.C. § 102. 

Furthermore, because Altova does not describe the manner in which it produces 
its results, this document is deficient under law because it is a non-enabling reference. 
Note MPEP § 2121. The Office Action states (on page 29) that the Applicant must 
supply facts to support its argument that Altova is non-enabling. The facts that support 
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Applicant's non- enablement argument mirror the facts set forth above with respect to the 
independent claims. To summarize, Altova describes, from only an end-user perspective, 
tools to display markup documents in multiple different views, but does not explain, from 
an enabling engineering perspective, how this operation is performed. Nor is the missing 
information inherently set forth by what Altova does describe. Since the claims of the 
present application are directed to a specific mechanism for mapping between two kinds 
of documents, and Altova provides no information regarding how it displays documents 
in different views, Altova is a non-enabling reference. 

For at least the above-identified reasons, the Applicant respectfully requests the 
Patent Office to remove the 35 U.S.C. § 102 rejection based on Altova. 

Conclusion 

The arguments presented above are not exhaustive; Applicant reserves the right to 
present additional arguments to fortify its position. Further, Applicant reserves the right 
to challenge the prior art status of one or more documents cited in the Office Action. 
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In conclusion, all objections and rejections raised in the Office Action having 
been addressed, it is respectfully submitted that the present application is in condition for 
allowance and such allowance is respectfully solicited. The Examiner is urged to contact 
the undersigned if any issues remain unresolved by this Amendment. 



Respectfully Submitted, 



Dated: 12-7-2006 By: 

David M. Huntley (J 
Reg. No. 40,309 
(509) 324-9256 



29 



